Speaker Kit

Building Software That Heals as Fast as It Breaks

Frontend engineers can ship excellent UIs while knowing very little about availability, SLOs, or delivery metrics. Many teams are set up that way, and it works, right up until reliability issues, slow rollbacks, or missed incidents start limiting impact and trust. This talk is about expanding the frontend role beyond the UI and into the system it runs inside. Not to turn frontend engineers into SREs, but to build enough systems awareness to make better tradeoffs. We’ll look at resilience as a delivery mindset, and how practices like atomic changes, trunk-based development, feature flags, and automated rollbacks directly influence availability and recovery, even when failures originate elsewhere. We’ll connect these practices to real constraints like SLOs and DORA metrics, and show why failure tolerance is contextual, from regulated systems where mistakes are expensive to product environments where controlled failure is acceptable. The goal is simple: help frontend engineers understand where their work fits in the system, so they can ship faster without increasing risk, make safer changes, and increase their leverage within a team.

Caching, Payloads, and Other Dark Arts: Optimizing UX in Suboptimal Conditions

This talk breaks down real world data fetching challenges at scale and how to solve them with modern patterns like the BFF layer, granular payload shaping, prefetching, and critical versus optimal queries. We walk through progressively improving an architecture that starts with five parallel client side requests against a bloated API, then move the work to a proxy handler, and finally to a fully optimized TanStack Query setup with server prefetching and resilient fallbacks. All demos were recorded on a long haul flight using in flight WiFi, showing how these patterns behave under real latency, unstable bandwidth, and failure conditions. The goal is to prove that these techniques are not academic. They directly affect reliability, performance, and user experience in harsh environments where debugging, caching strategy, and payload discipline make or break your product.

Delivered 13x

Engineering Without a Safety Net: Where It Works and Where It Hurts

Testing, monitoring, observability. They're rarely urgent, often skipped, and easy to dismiss when things are moving fast. But what's the real cost of deferring them, and how much can you actually get away with? This talk explores the tradeoffs of skipping traditional engineering practices in the name of speed, and what happens when you try to layer them in after a system has already scaled. It's not about dogma or checklists, it's about pragmatism, risk, and timing.

Delivered 3x

I Made a Million-Dollar Mistake, Now What?

We’ve all shipped something that cost money. An AWS service is left running. A misconfigured webhook. Test keys in production. Small mistakes, varying blast radius. But what happens when a system that serves tens of millions of users per month starts leaking revenue without ringing any alarm bells? Not through a massive crash, those are the easy ones to notice. But through partial failures that look “healthy” in most dashboards. This talk is a case study of a 13-year-old, bootstrapped product that has processed billions of requests, generates tens of millions in annual revenue, and is operated by roughly 10 engineers across the frontend and backend. In 24 hours, on the frontend alone, we can potentially amass over 120,000 errors, generate more logs than we can afford to retain in Datadog for more than two weeks, and other quirks that come with sheer scale. Failures are rarely total. They are regional, conditional, asynchronous, and financially expensive. We will analyze real postmortems in which losses accumulated silently over weeks (one even 9 months). We will explore how architecture across the stack, from React boundaries to API contracts to observability pipelines, determines whether you detect risk early or explain it later. This is not a blame story. It is not a hero story. It is a systems story. Because at scale, software will break. The question is whether your architecture tells you fast enough that it is costing you money and forgives you along the way.